Wrong Links following Project Archive/Restore

We've archived Project A under DOORS 8.3 and restored it as Project B in the same database to act as a sandbox.

Alarmed to see some links going to or coming from the correct module, but in the other project.

This problem is present with three archives taken of Project A at different times.

Each time the same archive file is restored, differing numbers of modules have wrong links.

Only one restore out of about half a dozen has no wrong links.

Some of the wrong links are visible at both ends others aren't.

What could be going wrong?
trak - Thu Aug 16 10:40:00 EDT 2012

Re: Wrong Links following Project Archive/Restore
llandale - Mon Aug 20 13:14:01 EDT 2012

Perhaps there is an old refresh problem. The links are there you just don't see them. I cannot find the old script that fixes these, but it does this:

mod = edit (each formal module in the Project) 

for obj in entire mod 

do 
{  

for lnk in obj ->
"*" 

do 
{  s = lnk.
"Created By"     
// just access the link 
} 
} save(mod)    
// no changes made, but save anyway close(mod)

-Louie

Re: Wrong Links following Project Archive/Restore
llandale - Mon Aug 20 13:15:59 EDT 2012

Maybe also you have an access problem. Have the "Administrator" restore the archive.

I wonder what happens if you archive something containing something you cannot read.

-Louie

Re: Wrong Links following Project Archive/Restore
trak - Tue Aug 21 12:13:07 EDT 2012

llandale - Mon Aug 20 13:15:59 EDT 2012
Maybe also you have an access problem. Have the "Administrator" restore the archive.

I wonder what happens if you archive something containing something you cannot read.

-Louie

Thanks,

Don't think it's an access problem. The first archive was taken by an Administrator and these wrong links were first noticed after he restored it.

Following the suggestion of a corrupted archive he made a second archive which he restored OK. (We use a script to open each module in turn and check if all the links are to the correct project).

I am a user whose powers include the archive and restore of modules and projects.

These wrong links are apparent when I restore his archive or one of my creation.

It isn't so much the visibility of the links that's the problem but the fact that some go the wrong project.

Project A and Project B may end up being two separate variant contracts immplemented by the same teams and we cannot tolerate the risk that someone
will open a link and start editting data in the wrong project.

Yes we know this isn't a sensible way to run a variant project, but we have customer constraints.

Another interesting fact is that usually the modules with the bad links are usually the first n to be examined by the script. Are modules looped in DXL in the order they would be restored from an archive?

Wrong links really are seen on the link arrows, so it's not the case of a bug in the script.

Apart from these wrong links no other problems have been observed with the restorations. A module hasn't been compared from two restorations but there are no obvious corruptions of object text.

As I said before, differing numbers of modules have wrong links each time the same archive is restored.

We operate in a Citrix environment and the 2GB archive file is held on a separate network drive.

The only suggestion I can make is that maybe some corporate security software or firewall is kicking in and delaying the start of the restore. This would explain the variability in the number of problem modules, but the restoration might be expected to fail totally.

If some key project/module data for links is held right at the start of the archive and if this is delayed DOORS starts off restoring regardless using the wrong project name for links.... Is this feasible?

Re: Wrong Links following Project Archive/Restore
trak - Tue Aug 21 12:28:43 EDT 2012

trak - Tue Aug 21 12:13:07 EDT 2012
Thanks,

Don't think it's an access problem. The first archive was taken by an Administrator and these wrong links were first noticed after he restored it.

Following the suggestion of a corrupted archive he made a second archive which he restored OK. (We use a script to open each module in turn and check if all the links are to the correct project).

I am a user whose powers include the archive and restore of modules and projects.

These wrong links are apparent when I restore his archive or one of my creation.

It isn't so much the visibility of the links that's the problem but the fact that some go the wrong project.

Project A and Project B may end up being two separate variant contracts immplemented by the same teams and we cannot tolerate the risk that someone
will open a link and start editting data in the wrong project.

Yes we know this isn't a sensible way to run a variant project, but we have customer constraints.

Another interesting fact is that usually the modules with the bad links are usually the first n to be examined by the script. Are modules looped in DXL in the order they would be restored from an archive?

Wrong links really are seen on the link arrows, so it's not the case of a bug in the script.

Apart from these wrong links no other problems have been observed with the restorations. A module hasn't been compared from two restorations but there are no obvious corruptions of object text.

As I said before, differing numbers of modules have wrong links each time the same archive is restored.

We operate in a Citrix environment and the 2GB archive file is held on a separate network drive.

The only suggestion I can make is that maybe some corporate security software or firewall is kicking in and delaying the start of the restore. This would explain the variability in the number of problem modules, but the restoration might be expected to fail totally.

If some key project/module data for links is held right at the start of the archive and if this is delayed DOORS starts off restoring regardless using the wrong project name for links.... Is this feasible?

I'm also interested to hear if archive/restore has been used by anyone to create a copy of a project in the same database.

If the usually usage is to replace a corrupted project that has been deleted, or to copy a project to another database, then this problem of links to the wrong project may be due to a bug in the tool not previously seen.

Re: Wrong Links following Project Archive/Restore
SystemAdmin - Tue Aug 21 15:38:36 EDT 2012

trak - Tue Aug 21 12:13:07 EDT 2012
Thanks,

Don't think it's an access problem. The first archive was taken by an Administrator and these wrong links were first noticed after he restored it.

Following the suggestion of a corrupted archive he made a second archive which he restored OK. (We use a script to open each module in turn and check if all the links are to the correct project).

I am a user whose powers include the archive and restore of modules and projects.

These wrong links are apparent when I restore his archive or one of my creation.

It isn't so much the visibility of the links that's the problem but the fact that some go the wrong project.

Project A and Project B may end up being two separate variant contracts immplemented by the same teams and we cannot tolerate the risk that someone
will open a link and start editting data in the wrong project.

Yes we know this isn't a sensible way to run a variant project, but we have customer constraints.

Another interesting fact is that usually the modules with the bad links are usually the first n to be examined by the script. Are modules looped in DXL in the order they would be restored from an archive?

Wrong links really are seen on the link arrows, so it's not the case of a bug in the script.

Apart from these wrong links no other problems have been observed with the restorations. A module hasn't been compared from two restorations but there are no obvious corruptions of object text.

As I said before, differing numbers of modules have wrong links each time the same archive is restored.

We operate in a Citrix environment and the 2GB archive file is held on a separate network drive.

The only suggestion I can make is that maybe some corporate security software or firewall is kicking in and delaying the start of the restore. This would explain the variability in the number of problem modules, but the restoration might be expected to fail totally.

If some key project/module data for links is held right at the start of the archive and if this is delayed DOORS starts off restoring regardless using the wrong project name for links.... Is this feasible?

You say that the archive was taken by AN administrator. Have you tried taking an archive as THE Administrator? That account is badly named, it should have been called 'Database Overlord' or 'The all powerful One'.
The Administrator account with username 'Administrator' is an account with no restrictions on permissions or visibility. I think that an archive will fail if you don't have access to something within the project (a vague memory, not a guarantee). I have restored archives to the same database in the past as a training project where I need multiple copies and have not seen this problem.
It doesn't sound like that is your problem but it is worth trying. Can you also try restoring to a different database, and then maybe restore a second copy to that same database. If that works then can you try taking an archive FROM that second database and restoring back in the original database?
I hope you are doing something a little odd here, the alternative is an unpredictable archive/restore process which is a very bad thought. This should really be raised with support because even if you are doing something non-standard, what you are describing should not happen.

Re: Wrong Links following Project Archive/Restore
llandale - Wed Aug 22 14:19:45 EDT 2012

trak - Tue Aug 21 12:13:07 EDT 2012
Thanks,

Don't think it's an access problem. The first archive was taken by an Administrator and these wrong links were first noticed after he restored it.

Following the suggestion of a corrupted archive he made a second archive which he restored OK. (We use a script to open each module in turn and check if all the links are to the correct project).

I am a user whose powers include the archive and restore of modules and projects.

These wrong links are apparent when I restore his archive or one of my creation.

It isn't so much the visibility of the links that's the problem but the fact that some go the wrong project.

Project A and Project B may end up being two separate variant contracts immplemented by the same teams and we cannot tolerate the risk that someone
will open a link and start editting data in the wrong project.

Yes we know this isn't a sensible way to run a variant project, but we have customer constraints.

Another interesting fact is that usually the modules with the bad links are usually the first n to be examined by the script. Are modules looped in DXL in the order they would be restored from an archive?

Wrong links really are seen on the link arrows, so it's not the case of a bug in the script.

Apart from these wrong links no other problems have been observed with the restorations. A module hasn't been compared from two restorations but there are no obvious corruptions of object text.

As I said before, differing numbers of modules have wrong links each time the same archive is restored.

We operate in a Citrix environment and the 2GB archive file is held on a separate network drive.

The only suggestion I can make is that maybe some corporate security software or firewall is kicking in and delaying the start of the restore. This would explain the variability in the number of problem modules, but the restoration might be expected to fail totally.

If some key project/module data for links is held right at the start of the archive and if this is delayed DOORS starts off restoring regardless using the wrong project name for links.... Is this feasible?

Well, DOORS does try to resolve stuff in Archives when the archive is restored in the exact database in which it was archived. Seems possible it may make some mistakes. Try this:
  • Login as the "Administrator", not some db-Admin
  • Archive the project
  • find another temp database, login as the Administrator
  • restore the project that other database
  • delete that 1st archive.
  • archive the project again.
  • login as the Administrator in the original
  • restore the 2nd archive.

Are all the links within the Project, or are there links going to something not being archived?

I wonder the access rights of the folder into which you are putting the archive. Make sure you have full RMCDA access.

-Louie